sdk-libs/program-test/src/indexer/test_indexer.rs (1)

2498-2534: ⚠️ Potential issue | 🔴 Critical

Non-2xx prover responses can hang this loop indefinitely.

When send() succeeds but the prover returns a 4xx/5xx, the loop neither decrements retries nor returns an error, so it can spin forever. The same block also still unwraps text() and deserialize_gnark_proof_json(), which reintroduces panics on malformed responses. Please route both status failures and decode failures through the same IndexerError path.

💡 Proposed fix

             let mut retries = 3;
             while retries > 0 {
                 let response_result = client
                     .post(format!("{}{}", SERVER_ADDRESS, PROVE_PATH))
                     .header("Content-Type", "text/plain; charset=utf-8")
                     .body(json_payload.clone())
                     .send()
                     .await;
-                if let Ok(response_result) = response_result {
-                    if response_result.status().is_success() {
-                        let body = response_result.text().await.unwrap();
-                        let proof_json = deserialize_gnark_proof_json(&body).unwrap();
+                match response_result {
+                    Ok(response_result) if response_result.status().is_success() => {
+                        let body = response_result
+                            .text()
+                            .await
+                            .map_err(|e| IndexerError::CustomError(e.to_string()))?;
+                        let proof_json = deserialize_gnark_proof_json(&body)
+                            .map_err(|e| IndexerError::CustomError(e.to_string()))?;
                         let (proof_a, proof_b, proof_c) = proof_from_json_struct(proof_json)
                             .map_err(|e| IndexerError::CustomError(e.to_string()))?;
                         let (proof_a, proof_b, proof_c) =
                             compress_proof(&proof_a, &proof_b, &proof_c)
                                 .map_err(|e| IndexerError::CustomError(e.to_string()))?;
                         return Ok(ValidityProofWithContext {
                             accounts: account_proof_inputs,
                             addresses: address_proof_inputs,
                             proof: CompressedProof {
                                 a: proof_a,
                                 b: proof_b,
                                 c: proof_c,
                             }
                             .into(),
                         });
                     }
-                } else {
-                    println!("Error: {:#?}", response_result);
-                    tokio::time::sleep(Duration::from_secs(5)).await;
-                    retries -= 1;
+                    Ok(response_result) => {
+                        let status = response_result.status();
+                        let body = response_result.text().await.unwrap_or_default();
+                        retries -= 1;
+                        if retries == 0 {
+                            return Err(IndexerError::CustomError(format!(
+                                "Prover returned {}: {}",
+                                status, body
+                            )));
+                        }
+                    }
+                    Err(err) => {
+                        retries -= 1;
+                        if retries == 0 {
+                            return Err(IndexerError::CustomError(err.to_string()));
+                        }
+                    }
                 }
+                tokio::time::sleep(Duration::from_secs(5)).await;
             }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@sdk-libs/program-test/src/indexer/test_indexer.rs` around lines 2498 - 2534,
The loop currently only decrements retries on transport errors and unwraps
response body and deserialization, causing hangs or panics for non-2xx or
malformed responses; change the logic in the while retries loop that starts with
`let response_result = client.post(...).send().await` to treat any non-success
status as a failure path that decrements `retries`, sleeps, and eventually
returns an `IndexerError::CustomError` if exhausted. Specifically: when
`response_result` is Ok but `response_result.status().is_success()` is false,
read the body safely (await and map errors) and convert the status+body into an
`IndexerError::CustomError`, decrement `retries` and sleep before retrying;
replace all `.unwrap()` calls on `response_result.text().await` and
`deserialize_gnark_proof_json(&body)` with error-mapped returns into
`IndexerError::CustomError`; keep the successful branch that calls
`proof_from_json_struct` and `compress_proof` but also map their errors (they
already use map_err) and ensure any failure there returns
`Err(IndexerError::CustomError(...))` rather than panicking. This ensures
`retries` is decremented for both transport and non-2xx responses and avoids
unwrap-induced panics while preserving use of `deserialize_gnark_proof_json`,
`proof_from_json_struct`, `compress_proof`, `ValidityProofWithContext`, and
`CompressedProof`.

prover/client/src/proof_types/batch_address_append/proof_inputs.rs (1)

556-559: 🧹 Nitpick | 🔵 Trivial

Redundant slice: [0..] is unnecessary.

new_element_values[0..] is equivalent to just new_element_values. This appears to be a leftover from a refactor.

✨ Suggested simplification

-        new_element_values: new_element_values[0..]
-            .iter()
+        new_element_values: new_element_values
+            .iter()

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/src/proof_types/batch_address_append/proof_inputs.rs` around
lines 556 - 559, The slice new_element_values[0..] is redundant; update the
mapping to iterate directly over new_element_values (i.e., replace
new_element_values[0..].iter() with new_element_values.iter()) so the BigUint
conversion via BigUint::from_bytes_be(v) and the collect() behavior remain
unchanged; touch the expression in proof_inputs.rs where new_element_values is
used in the map to remove the unnecessary slice.

prover/client/src/helpers.rs (1)

49-54: ⚠️ Potential issue | 🟠 Major

Widen path_index before address trees cross u32::MAX.

compute_root_from_merkle_proof is now the shared fallible helper for both state and address trees, but it still encodes the path index as u32. The address-append callers already hold usize/u64 indices for 40-level trees and currently downcast into this API; once next_index exceeds 4_294_967_295, those casts will silently truncate the upper bits and compute the wrong root and changelog. Use usize or u64 here and narrow only at a boundary that truly requires it.

Based on learnings: Address trees must initialize with ADDRESS_TREE_INIT_ROOT_40 (hardcoded for height 40) and start with next_index = 1.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/src/helpers.rs` around lines 49 - 54, The function
compute_root_from_merkle_proof currently accepts path_index: u32 which causes
truncation for address trees deeper than u32::MAX; change the parameter to a
wider integer (prefer usize or u64) in the signature and all internal uses
(e.g., ChangelogEntry::default_with_index call and any arithmetic) and only
downcast to u32 at the true boundary if an API you call requires u32; also
update any callers that downcast from usize/u64 to pass the wider type.
Additionally ensure address-tree initialization uses ADDRESS_TREE_INIT_ROOT_40
and that the address-tree next_index starts at 1 (update
constructors/initializers that set next_index) so address trees for height 40
behave correctly.

prover/client/src/proof_types/batch_append/proof_inputs.rs (1)

180-194: ⚠️ Potential issue | 🟠 Major

Remove the remaining proof-length panic in this path.

The new ? only covers compute_root_from_merkle_proof; merkle_proof.try_into().unwrap() still aborts the process if the indexer returns a proof with the wrong height. This function already returns ProverClientError, so surface the mismatch instead of panicking.

Suggested fix

-        let merkle_proof_array = merkle_proof.try_into().unwrap();
+        let proof_len = merkle_proof.len();
+        let merkle_proof_array: [[u8; 32]; HEIGHT] = merkle_proof.try_into().map_err(|_| {
+            ProverClientError::GenericError(format!(
+                "Invalid merkle proof length: got {}, expected {}",
+                proof_len, HEIGHT
+            ))
+        })?;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/src/proof_types/batch_append/proof_inputs.rs` around lines 180
- 194, The code still panics on merkle_proof.try_into().unwrap(); replace the
unwrap with fallible conversion that returns a ProverClientError instead of
aborting: call merkle_proof.try_into().map_err(|e|
ProverClientError::InvalidProofLength { source: e.into(), context:
format!("expected height for index {}", start_index + i as u32) })? (or perform
a match and return an appropriate ProverClientError), then continue using
merkle_proof_array with compute_root_from_merkle_proof(final_leaf,
&merkle_proof_array, start_index + i as u32)? so the function surfaces
proof-length mismatches via its existing ProverClientError return type rather
than panicking on unwrap.

prover/client/src/proof_types/batch_update/proof_inputs.rs (1)

171-178: ⚠️ Potential issue | 🟠 Major

Finish the fallible-path cleanup in get_batch_update_inputs.

This call site now propagates compute_root_from_merkle_proof, but the proof conversion and Poseidon::hashv immediately above still unwrap(). A malformed proof or invalid hash input will still panic the process instead of returning ProverClientError.

Suggested fix

-        let merkle_proof_array = merkle_proof.try_into().unwrap();
+        let proof_len = merkle_proof.len();
+        let merkle_proof_array: [[u8; 32]; HEIGHT] = merkle_proof.try_into().map_err(|_| {
+            ProverClientError::GenericError(format!(
+                "Invalid merkle proof length: got {}, expected {}",
+                proof_len, HEIGHT
+            ))
+        })?;
@@
-        let nullifier = Poseidon::hashv(&[leaf, &index_bytes, &tx_hashes[i]]).unwrap();
+        let nullifier = Poseidon::hashv(&[leaf, &index_bytes, &tx_hashes[i]])?;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/src/proof_types/batch_update/proof_inputs.rs` around lines 171
- 178, The code in get_batch_update_inputs currently uses
merkle_proof.try_into().unwrap() and Poseidon::hashv(...).unwrap(), which can
panic; change both to propagate errors as ProverClientError instead: replace
merkle_proof.try_into().unwrap() with merkle_proof.try_into().map_err(|e|
ProverClientError::from(...))? (or an appropriate ProverClientError variant) and
replace Poseidon::hashv(...).unwrap() with Poseidon::hashv(...).map_err(|e|
ProverClientError::from(...))? so that malformed proofs or hash failures return
an Err from get_batch_update_inputs and remain consistent with the
compute_root_from_merkle_proof error propagation.

prover/client/src/proof_types/batch_address_append/proof_inputs.rs (1)

369-489: ⚠️ Potential issue | 🟠 Major

Keep the staging mutations transactional on Err.

This function now returns recoverable errors after it has already pushed into changelog / indexed_changelog and mutated sparse_merkle_tree (for example the later compute_root_from_merkle_proof(...) ? calls and the final ordering check). If any of those fail, the caller gets Err but the local staging state is left partially advanced, so the next retry or batch runs against corrupted state. Build into temporary state and commit only once the whole batch succeeds, or add explicit rollback.

Also applies to: 500-518

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/src/proof_types/batch_address_append/proof_inputs.rs` around
lines 369 - 489, The code mutates staging state (changelog, indexed_changelog,
sparse_merkle_tree, and pushes via patcher.push_changelog_entry::<HEIGHT>,
sparse_merkle_tree.append, and indexed_changelog.push) before fallible
operations complete, so on Err the local state is partially advanced; fix by
performing all fallible computations on temporary/clone state (clone
sparse_merkle_tree, collect changelog entries and merkle proof arrays into local
Vecs like new_element_circuit_merkle_proofs_tmp / indexed_changelog_tmp) and
only call patcher.push_changelog_entry::<HEIGHT>, sparse_merkle_tree.append (or
replace the real tree), and indexed_changelog.push once the entire batch loop
finishes successfully; alternatively implement an explicit rollback path that
reverts mutations (undo append and pop changelog) on any early Err — apply same
change for the other block around lines 500-518 where similar pushes occur.

sdk-libs/program-test/src/indexer/test_indexer.rs (1)

2500-2514: ⚠️ Potential issue | 🔴 Critical

Non-2xx prover responses hot-loop forever here.

When send() succeeds but the prover returns 4xx/5xx, retries is never decremented and the loop immediately issues another request. That turns a transient server error into an unbounded tight retry, and the adjacent unwrap() calls on text() / deserialize_gnark_proof_json() still panic on malformed responses instead of surfacing IndexerError.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@sdk-libs/program-test/src/indexer/test_indexer.rs` around lines 2500 - 2514,
The loop currently treats any Ok(response) the same and only decrements retries
on send() errors, causing tight infinite retries for 4xx/5xx and panics from
unwrap() on malformed bodies; update the block that handles Ok(response_result)
so that non-success HTTP statuses decrement retries (and optionally sleep)
instead of immediately retrying, and convert the body/text and JSON parsing
unwraps into fallible operations that map errors into IndexerError (e.g. replace
response_result.text().await.unwrap() and
deserialize_gnark_proof_json(...).unwrap() with ?-style error mapping to
IndexerError), and ensure that any failure in proof_from_json_struct or
compress_proof is returned as Err(IndexerError::CustomError(...)) rather than
panicking; reference the response handling around deserialize_gnark_proof_json,
proof_from_json_struct, compress_proof and IndexerError to locate the changes.

forester/src/processor/v2/strategy/address.rs (1)

269-308: ⚠️ Potential issue | 🟠 Major

Require a full ZKP batch before calling process_batch.

StreamingAddressQueue::wait_for_batch() can return early after its timeout, so get_batch_snapshot() may hand back fewer than zkp_batch_size_usize addresses. Feeding addresses.len() downstream as zkp_batch_size_actual turns that short snapshot into a real address-append job instead of treating it as "not ready yet", which means a slow indexer can produce inputs for an unsupported circuit size.

Suggested guard

-        let zkp_batch_size_actual = addresses.len();
+        if addresses.len() != zkp_batch_size_usize {
+            return Ok(None);
+        }
         let result = staging_tree
             .process_batch(
                 &addresses,
                 &low_element_values,
                 &low_element_next_values,
                 &low_element_indices,
                 &low_element_next_indices,
                 &low_element_proofs,
                 leaves_hashchain,
-                zkp_batch_size_actual,
+                zkp_batch_size_usize,
                 epoch,
                 tree,
             )

Based on learnings: ZKP batch sizes for address trees must be 10 or 250 in src/initialize_address_tree.rs. Only these circuit sizes are supported for address trees.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@forester/src/processor/v2/strategy/address.rs` around lines 269 - 308, The
snapshot returned by StreamingAddressQueue::get_batch_snapshot may be shorter
than the ZKP batch size; before calling staging_tree.process_batch, verify that
addresses.len() equals zkp_batch_size_usize (the expected batch size) and, if it
is smaller, treat the batch as "not ready" (do not call process_batch) — e.g.,
return/propagate a no-op/NotReady result or retry later. Update the logic around
AddressBatchSnapshot retrieval (get_batch_snapshot::<{
DEFAULT_BATCH_ADDRESS_TREE_HEIGHT as usize }>) to check zkp_batch_size_actual
against zkp_batch_size_usize and only pass a full batch into
staging_tree.process_batch; ensure the code path preserves the existing error
mapping via map_address_staging_error when a full batch is processed.

prover/client/src/helpers.rs (1)

49-54: ⚠️ Potential issue | 🟠 Major

Make path_index wide enough for address-tree indices.

The helper is now HEIGHT-generic, but path_index is still u32. The new address-append callers already hold indices as usize and have to downcast them with as u32; once an address tree passes u32::MAX, root reconstruction will wrap and produce the wrong path/changelog long before the tree is full.

Proposed fix

 pub fn compute_root_from_merkle_proof<const HEIGHT: usize>(
     leaf: [u8; 32],
     path_elements: &[[u8; 32]; HEIGHT],
-    path_index: u32,
+    path_index: usize,
 ) -> Result<([u8; 32], ChangelogEntry<HEIGHT>), ProverClientError> {
-    let mut changelog_entry = ChangelogEntry::default_with_index(path_index as usize);
+    let mut changelog_entry = ChangelogEntry::default_with_index(path_index);
 
     let mut current_hash = leaf;
     let mut current_index = path_index;

Then update the address-append call sites to pass low_element.index, new_low_element.index, and current_index directly, without lossy casts.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/src/helpers.rs` around lines 49 - 54, The function
compute_root_from_merkle_proof currently takes path_index: u32 which can
overflow for large address trees; change its signature to accept path_index:
usize and update the internal use of
ChangelogEntry::default_with_index(path_index as usize) to pass the usize
directly (ChangelogEntry::default_with_index(path_index)), then update all
callers (the address-append sites that currently cast indices with as u32) to
pass their usize indices directly (e.g., low_element.index,
new_low_element.index, current_index) so there is no lossy cast or potential
wrap-around.

prover/client/tests/batch_address_append.rs (1)

87-109: 🧹 Nitpick | 🔵 Trivial

Add a non-empty changelog regression here.

This test still starts with empty changelog and indexed_changelog, so it only exercises the first-batch branch. The new proof-patching logic is only used once those vectors already contain prior entries, which is the riskier path introduced in this PR.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/tests/batch_address_append.rs` around lines 87 - 109, The test
currently initializes changelog and indexed_changelog as empty vectors so
get_batch_address_append_circuit_inputs only covers the first-batch path;
pre-populate both changelog: Vec<ChangelogEntry<{
DEFAULT_BATCH_ADDRESS_TREE_HEIGHT as usize }>> and indexed_changelog:
Vec<IndexedChangelogEntry<usize, { DEFAULT_BATCH_ADDRESS_TREE_HEIGHT as usize
}>> with one or more realistic entries (matching the ChangelogEntry and
IndexedChangelogEntry shapes used elsewhere in tests) before calling
get_batch_address_append_circuit_inputs so the function exercises the
proof-patching logic for non-empty prior entries; ensure the synthetic entries
use valid roots/indices/values consistent with the sparse_merkle_tree and
DEFAULT_BATCH_ADDRESS_TREE_HEIGHT expectations.

prover/client/src/proof_types/batch_update/proof_inputs.rs (1)

139-178: ⚠️ Potential issue | 🟠 Major

Fail fast on mismatched batch-update inputs.

This loop only zips leaves, merkle_proofs, and path_indices, but still indexes tx_hashes[i]. A short tx_hashes vector, a short proof, or a hash failure still panics here even after making compute_root_from_merkle_proof() fallible.

Possible fix

+    let expected_len = batch_size as usize;
+    if tx_hashes.len() != expected_len
+        || leaves.len() != expected_len
+        || old_leaves.len() != expected_len
+        || merkle_proofs.len() != expected_len
+        || path_indices.len() != expected_len
+    {
+        return Err(ProverClientError::GenericError(format!(
+            "Input vector length mismatch: tx_hashes={}, leaves={}, old_leaves={}, merkle_proofs={}, path_indices={}, expected={}",
+            tx_hashes.len(),
+            leaves.len(),
+            old_leaves.len(),
+            merkle_proofs.len(),
+            path_indices.len(),
+            expected_len,
+        )));
+    }
+
-    for (i, (leaf, (mut merkle_proof, index))) in leaves
+    for (i, ((leaf, tx_hash), (mut merkle_proof, index))) in leaves
         .iter()
-        .zip(merkle_proofs.into_iter().zip(path_indices.iter()))
+        .zip(tx_hashes.iter())
+        .zip(merkle_proofs.into_iter().zip(path_indices.iter()))
         .enumerate()
     {
@@
-        let merkle_proof_array = merkle_proof.try_into().unwrap();
+        let proof_len = merkle_proof.len();
+        let merkle_proof_array: [[u8; 32]; HEIGHT] = merkle_proof.try_into().map_err(|_| {
+            ProverClientError::GenericError(format!(
+                "Invalid merkle proof length: got {}, expected {}",
+                proof_len, HEIGHT
+            ))
+        })?;
@@
-        let nullifier = Poseidon::hashv(&[leaf, &index_bytes, &tx_hashes[i]]).unwrap();
+        let nullifier = Poseidon::hashv(&[leaf, &index_bytes, tx_hash])?;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/src/proof_types/batch_update/proof_inputs.rs` around lines 139
- 178, The loop can panic because tx_hashes is indexed by i while the zip only
covers leaves, merkle_proofs and path_indices; validate input lengths up front
or include tx_hashes in the zip to avoid out-of-bounds access and remove
unwraps: check that leaves.len() == merkle_proofs.len() == path_indices.len() ==
tx_hashes.len() and return a ProverClientError if not, replace
merkle_proof.try_into().unwrap() with a fallible conversion that maps the error
into ProverClientError, and ensure Poseidon::hashv and
compute_root_from_merkle_proof errors are propagated rather than causing panics.

prover/client/src/proof_types/batch_append/proof_inputs.rs (1)

135-194: ⚠️ Potential issue | 🟠 Major

Validate the batch-append inputs before building the circuit.

This loop truncates to the shortest of old_leaves, leaves, and merkle_proofs, so a mismatch can silently produce fewer append proofs than batch_size claims. merkle_proof.try_into().unwrap() also still turns a bad indexer response into a panic instead of a ProverClientError.

Possible fix

+    let expected_len = batch_size as usize;
+    if old_leaves.len() != expected_len
+        || leaves.len() != expected_len
+        || merkle_proofs.len() != expected_len
+    {
+        return Err(ProverClientError::GenericError(format!(
+            "Input vector length mismatch: old_leaves={}, leaves={}, merkle_proofs={}, expected={}",
+            old_leaves.len(),
+            leaves.len(),
+            merkle_proofs.len(),
+            expected_len,
+        )));
+    }
+
     for (i, (old_leaf, (new_leaf, mut merkle_proof))) in old_leaves
         .iter()
         .zip(leaves.iter().zip(merkle_proofs.into_iter()))
         .enumerate()
     {
@@
-        let merkle_proof_array = merkle_proof.try_into().unwrap();
+        let proof_len = merkle_proof.len();
+        let merkle_proof_array: [[u8; 32]; HEIGHT] = merkle_proof.try_into().map_err(|_| {
+            ProverClientError::GenericError(format!(
+                "Invalid merkle proof length: got {}, expected {}",
+                proof_len, HEIGHT
+            ))
+        })?;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@prover/client/src/proof_types/batch_append/proof_inputs.rs` around lines 135
- 194, The loop silently truncates to the shortest iterator (old_leaves, leaves,
merkle_proofs) and panics on invalid proof conversion; validate input lengths
and convert safely before building the circuit: check that old_leaves.len(),
leaves.len(), and merkle_proofs.len() equal batch_size (and/or start_index +
batch_size bounds) and return a ProverClientError on mismatch; replace
merkle_proof.try_into().unwrap() with a fallible conversion that maps the error
into ProverClientError (maintain context like current_index and batch_position);
keep remaining logic (is_old_leaf_zero, compute_root_from_merkle_proof)
unchanged.

sdk-libs/sdk-types/src/interface/account/token_seeds.rs (1)

268-280: ⚠️ Potential issue | 🟠 Major

Don’t silently ignore output_queue_index; enforce consistency or remove it end-to-end.

Line 268 makes output_queue_index unused, while Line 280 now sources queue_pubkey_index only from tree_info. Since callers still pass output_queue_index (see sdk-libs/sdk-types/src/interface/program/decompression/token.rs), mismatches become silent and can produce incorrect merkle context assembly.

Proposed guard to prevent silent divergence

     fn into_in_token_data(
         &self,
         tree_info: &PackedStateTreeInfo,
-        _output_queue_index: u8,
+        output_queue_index: u8,
     ) -> Result<MultiInputTokenDataWithContext, LightSdkTypesError> {
+        if output_queue_index != tree_info.queue_pubkey_index {
+            return Err(LightSdkTypesError::InvalidInstructionData);
+        }
         Ok(MultiInputTokenDataWithContext {
             amount: self.token_data.amount,
             mint: self.token_data.mint,
             owner: self.token_data.owner,
             version: self.token_data.version,
             has_delegate: self.token_data.has_delegate,
             delegate: self.token_data.delegate,
             root_index: tree_info.root_index,
             merkle_context: PackedMerkleContext {
                 merkle_tree_pubkey_index: tree_info.merkle_tree_pubkey_index,
-                queue_pubkey_index: tree_info.queue_pubkey_index,
+                queue_pubkey_index: output_queue_index,
                 leaf_index: tree_info.leaf_index,
                 prove_by_index: tree_info.prove_by_index,
             },
         })
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@sdk-libs/sdk-types/src/interface/account/token_seeds.rs` around lines 268 -
280, The function currently accepts output_queue_index but ignores it when
building PackedMerkleContext (using tree_info.queue_pubkey_index), which can
cause silent mismatches; update the constructor logic in the function that
returns MultiInputTokenDataWithContext to either (a) validate that
output_queue_index == tree_info.queue_pubkey_index and return an Err on
mismatch, or (b) use the provided output_queue_index when setting
PackedMerkleContext.queue_pubkey_index (and document the precedence), and ensure
callers in token.rs remain compatible; refer to symbols output_queue_index,
tree_info, PackedMerkleContext, and MultiInputTokenDataWithContext to locate and
fix the code path.